This page collects related topics on a single HTML page: Create a Physical Data Service from a Java Function Physical Data Services from Java Functions Overview Preparing to Create Physical Data Services From Java Functions Creating XMLBean Support for Java Functions You may find this more convenient for printing purposes.

eDocs Home > BEA AquaLogic Data Services Platform Documentation > Data Services Developer's Guide > Contents

How To Create a Physical Data Service from a Java Function

Prefer all related topic on a Single Page? Click here.

You can create physical data services based on custom Java functions that return both simple and complex types.

Before you can create physical data services based on custom Java functions, you must create a Java class containing both the schema and function information. For more information, see Preparing to Create Physical Data Services From Java Functions. For more information about supported Java types and the corresponding generated data services, see Physical Data Services from Java Functions Overview.

Topics 

Setting Up the Physical Data Service Creation Wizard

Physical data services are created using a wizard.

Physical Data Service Creation Wizard

Starting the Wizard

To start the physical data service creation wizard:

1. Right-click on your dataspace project or any folder in your project.
2. Choose New > Physical Data Service

Creating a New Physical Data Service

Accessing Java Functions

After you choose Java Function as your data source, you need to specify a class name containing the Java functions.

Choosing Java Function as a Data Source

Choosing the Java class:

To choose the Java class containing the Java functions:

1. Choose Java Function from the Data source type drop-down list.
2. Click Browse. The Open Java Class dialog appears.
3. Select the Java .class file and click Open.
   The .class file must reside in the same dataspace into which you are importing the Java functions.
4. Click Next.

Open Java Class Dialog

Selecting Java Functions to Import

After you select Java Function as your data source, you need to select the Java functions to import.

Selecting Java Function Dialog

To select the Java functions to import:

1. Select the Java functions you want to import by checking the corresponding box.
   Select With Change Summary to have ALDSP declare the parameter or return value as changed-element enabling you to use it with update operations. This option is only available for SDO DataObject-generated classes.
2. Click Next.

Setting Characteristics of Imported Java Functions

After choosing the Java functions to import, you can optionally set the characteristics of the functions.

Setting Characteristics of Imported Java Functions 

The following table describes the available options for each function you have selected to import.

Options Available for Imported Java Functions

Characteristic	Options	Comment
Operation name	Adjust as needed	You can change the nominated name to any legal XML name using the built-in line editor.
Public	Boolean	By default Java function-derived operations are protected. A checkbox allows you to mark any function or procedure as public. (Once in a data service, operations can be marked private as needed.)
Kind	Read Create Update Delete Library function Library procedure	Functions determined to return void are automatically marked as library procedures. You can change the nominated function type. The wizard attempts to correctly set the function type being imported. Operations marked as create, update, or delete functions will be packaged in an Entity data service. Otherwise, the resulting data service will be of type Library.
is Primary	Boolean	Not applicable for Java functions.
Root Element	Root element of the operation	For complex data types the topmost element is listed.
Target Namespace	Imported value	This represents the target namespace of the generated data service.

To set the characteristics of imported Java functions:

1. Optionally edit the details of each operation:
2. Click Next.
   

Setting the Physical Data Service Name

You can set the name of your data service to any legal name that does not conflict with another name in the current dataspace.

To  complete the wizard:

1. Type the name of the data service in the Data service name field.
2. Click Finish.

ALDSP creates a pragma (visible in Source view) that defines the function signature and relevant schema type for complex types such as schema elements or SDO types.

If there are existing data services in your project, you have the option of adding functions and procedures to that library or creating a new library for them. All the Java file functions are located in the same data service.

When importing a Java function that itself has one or more dependent (or referenced) schemas, the wizard creates second-level schemas according to internal naming conventions. If several operations reference the same secondary schemas, the generated name for the secondary schema may change if you re-import or synchronize with the Java class.

See Also

Concepts

•   Physical Data Services from Java Functions Overview

How Tos

•   Preparing to Create Physical Data Services From Java Functions
•   Creating XMLBean Support for Java Functions

eDocs Home > BEA AquaLogic Data Services Platform Documentation > Data Services Developer's Guide > Contents

Physical Data Services from Java Functions Overview

In AquaLogic Data Services Platform (ALDSP), you can create physical data services based on user-defined functions implemented as Java classes. ALDSP supports Java functions returning the following types:

• Java primitive types and single-dimension arrays
• Global elements and global element arrays through XMLBean classes
• Global elements and global element arrays through SDO DataObjects

ALDSP packages operations marked as create, update, or delete functions in an Entity data service. Otherwise, the resulting data service is of type Library. Functions determined to return void are automatically marked as library procedures. When creating a new physical data service, you can change the nominated function type.

The Java method name, when used in an XQuery, becomes the XQuery function name qualified with a namespace.

The following restrictions apply to Java functions: Java functions intended for import into a data service must be declared as static Function overloading is based on the number of arguments, not the parameter types Array support is restricted to single-dimension arrays only In functions returning complex types, the return element needs to be extracted from a valid XML document

Simple Java Types and Their XQuery Counterparts

The following outlines the mapping between simple Java types and the corresponding XQuery or schema types:

Java functions can consume parameters and return values of the following types:

• Java primitives and types listed in the previous table
• Apache XMLBeans
• BEA XMLBeans
• SDO DataObject (typed or untyped)

  The elements or types referred to in the schema should be global elements.

Physical Data Service from a Java Function - Example Code

This topic provides examples showing the use of imported Java functions in an XQuery and the processing of complex types.

Using a Function Returning an Array of Java Primitives

As an example, the Java function getRunningTotal can be defined as follows:

public static float[] getRunningTotal(float[] list) {
   if (null == list || 1 >= list.length)
      return list;
   for (int i = 1; i < list.length; i++) {
      list[i] = list[i-1] + list[i];
   }
   return list;
}

The corresponding XQuery for executing the above function is as follows:

Declare namespace f1="ld:javaFunc/float"
Let $y := (2.0, 4.0, 6.0, 8.0, 10.0)
Let $x := f1:getRunningTotal($y)
Return $x

The results of the query is as follows:

2.0, 6.0, 12.0, 20.0, 30.0

Processing complex types represented via XMLBeans

Consider a schema called Customer (customer.xsd), as shown in the following:

<?xml version="1.0" encoding="UTF-8" ?>
   <xs:schema targetNamespace="ld:xml/cust:/BEA_BB10000" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="CUSTOMER">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="FIRST_NAME" type="xs:string" minOccurs="1"/>
            <xs:element name="LAST_NAME" type="xs:string" minOccurs="1"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
</xs:schema>

You could compile the schema using XMLBeans to generate a Java class corresponding to the types in the schema.

xml.cust.beaBB10000.CUSTOMERDocument.CUSTOMER

For more information, see http://xmlbeans.apache.org.

Following this, you can use the CUSTOMER element as shown in the following:

public static xml.cust.beaBB10000.CUSTOMERDocument.CUSTOMER[]
      getCustomerListGivenCustomerList(xml.cust.beaBB10000.CUSTOMERDocument.CUSTOMER[] ipListOfCust)
      throws XmlException {
   xml.cust.beaBB10000.CUSTOMERDocument.CUSTOMER [] mylocalver = pListOfCust;
   return mylocalver;
}

The resulting metadata information produced by the New Physical Data Service wizard will be:

(::pragma function <f:function xmlns:f="urn:annotations.ld.bea.com" kind="datasource" access="public">
<params>
<param nativeType="[Lxml.cust.beaBB10000.CUSTOMERDocument$CUSTOMER;"/>
</params>
</f:function>::)

declare function f1:getCustomerListGivenCustomerList($x1 as element(t1:CUSTOMER)*) as element(t1:CUSTOMER)* external;

The corresponding XQuery for executing the above function is:

declare namespace f1 = "ld:javaFunc/CUSTOMER";
let $z := (
validate(<n:CUSTOMER xmlns:n="ld:xml/cust:/BEA_BB10000"><FIRST_NAME>John2</FIRST_NAME><LAST_NAME>Smith2</LAST_NAME>
</n:CUSTOMER>),

validate(<n:CUSTOMER xmlns:n="ld:xml/cust:/BEA_BB10000"><FIRST_NAME>John2</FIRST_NAME><LAST_NAME>Smith2</LAST_NAME>
</n:CUSTOMER>),

validate(<n:CUSTOMER xmlns:n="ld:xml/cust:/BEA_BB10000"><FIRST_NAME>John2</FIRST_NAME><LAST_NAME>Smith2</LAST_NAME>
</n:CUSTOMER>),

validate(<n:CUSTOMER xmlns:n="ld:xml/cust:/BEA_BB10000"><FIRST_NAME>John2</FIRST_NAME><LAST_NAME>Smith2</LAST_NAME>
</n:CUSTOMER>))

for $zz in $z
return

See Also

How Tos

•   Create a Physical Data Service from a Java Function
•   Preparing to Create Physical Data Services From Java Functions

eDocs Home > BEA AquaLogic Data Services Platform Documentation > Data Services Developer's Guide > Contents

Preparing to Create Physical Data Services From Java Functions

This topic provides an overview of how to create a new physical data service from Java functions. 

Before you can create physical data services based on custom Java functions, you need to create a Java class containing both the schema and function information. The entire process involves the following:

1. Using Apache XMLBeans, BEA XMLBeans, or SDO DataObjects, create a schema of the data that is being used as parameters and return values by the Java functions.
2. Create the XMLBean classes or SDO DataObject classes and package them in a JAR file.
   

   For more information, see Creating XMLBean Support for Java Functions.

3. Place the JAR file in the DSP-INF/lib folder of the project in which you want to create the new Physical Data Service.
4. Create the new Physical Data Service based on your custom Java functions by importing the corresponding .class file.
   

   For more information, see Create a Physical Data Service from a Java Function.

See Also

Concepts

•   Physical Data Services from Java Functions Overview

How Tos

•   Create a Physical Data Service from a Java Function
•   Creating XMLBean Support for Java Functions

eDocs Home > BEA AquaLogic Data Services Platform Documentation > Data Services Developer's Guide > Contents

Creating XMLBean Support for Java Functions

Before you can create a Physical Data Service from Java functions, you need to create a .class file that contains XMLBean classes based on global elements and compiled versions of your Java functions. This topic describes how to create XMLBean classes based on a schema of your data.

Supported XMLBean Standards

Imported Java functions containing complex types must have a schema that conforms to one of the following XMLBean standards:

If your Java routines were compiled under previous versions, they will need to be recompiled before they can be imported.

The New Physical Data Service wizard requires that all the complex parameter or return types used by the functions correspond to XMLBean global element types whose content model is an anonymous type. Thus only functions referring to a top level element are imported.

Creating XMLBean Classes for Java Functions

This topic describes how to create XMLBean classes based on a schema of your data.

Creating a New Project

You need to create a new project to build the XMLBean classes.

New Project

To create a new project:

1. Using WorkSpace Studio, create a new project by right-clicking in the Project Explorer and choosing New > Project in the menu. The New Project wizard is launched.
2. Choose Java > Java Project and click Next.
3. Type a name for the project and select Create separate source and output folders in the Project layout area.
4. Click Finish. WorkSpace Studio creates a new project in the Project Explorer.

New Java Project Wizard

Enabling XMLBeans Builder

You need to enable the XMLBeans Builder in the project to allow it to create classes based on the Java source and XML schema files.

Project Properties

To enable XMLBeans Builder:

1. Right-click the new project, and choose Properties from the menu. The Properties dialog appears.
2. Click XMLBeans, select the Enable XMLBeans Builder checkbox, and click OK.

Enabling XMLBeans Builder

Importing Schema and Java Source Files

You need to import the schema files and Java source files into the project.

To import the schema and Java source files:

• Copy the schema files representing the data used by the Java functions along with the Java source files into the src folder.

Creating a Project Reference

The final step involves creating a reference to your XMLBeans-based project from the dataspace in which you want to use the Java functions.

To create the project reference:

1. Right-click the dataspace project in which you want to use the Java functions and choose Properties from the menu.
2. Select Project References in the Properties dialog.
3. Select your XMLBeans-based project, and click OK.

When your project is deployed, ALDSP does the following:

• Rebuilds your XMLBeans-based project, if required, and generates a JAR file
• Copies the JAR file to the DSP-INF/lib folder in the dataspace project

Project References

See Also

How Tos

•   Create a Physical Data Service from a Java Function

Reference

•   Physical Data Services from Java Functions Overview
•   XMLBeans Example Using a Metadata-rich Java Class